Typically, one or more services (e.g., voice, video, data, etc.) are provided to a subscriber from a multiple systems operator (MSO). The one or more services are generally delivered to a central device or access point (e.g., modem, router, gateway, etc.) located within a subscriber premise, and the central device or access point forwards the services to one or more client devices (i.e., host devices). A central device or access point typically operates in a NAT (Network Address Translation) route mode to route communications through the device and onto a targeted client or host device. For example, using an embedded modem, the central device or access point will usually route communications from a wide area network (WAN) (e.g., cable, digital subscriber line (DSL), fiber, etc.) to a local area network (LAN) (e.g., Ethernet, Wi-Fi, multimedia over coax alliance (MoCA), etc.). NAT allows private internal Internet protocol (IP) addresses (i.e., LAN hosts) to be mapped to a single external IP address (e.g., WAN address of the central device/access point). A central device/access point will typically run a DHCP (Dynamic Host Configuration Protocol) server application on a LAN side to assign private IP address to LAN hosts (e.g., client devices).
This home network deployment has the side effect of hiding the internal hosts, and a WAN side DHCP server is left without the ability to allocate an address to a specific LAN device (e.g., STB (Set Top Box), ATA (Analog Telephone Adaptor), etc.) directly. Thus, all the data traffic has to be routed at Internet layer (Layer 3, IP layer) by the central device/access point.
In some instances, a central device/access point may be placed in a full bridge mode. For example, in order to access a LAN host, some firewall rules like demilitarized zone (DMZ) or port forwarding may be configured in the central device/access point. However, for DMZ, only one host can be configured, and for Port Forwarding, knowledge of the application port numbers is required. These problems may be solved by placing the central device/access point into a full bridge mode, but the central device/access point will lose the ability to route packets while operating in full bridge mode.
At times, it may be desirable to put one or more specific devices to work under a bridge mode. For example, an operator may want to give specific DHCP options to certain STBs situated behind a central device/access point. Individual devices (e.g., individual STBs) may be identified by a unique address. For example, a media access control (MAC) address may be identified from the first 3 bytes of a data packet (e.g., OUI (Organizationally Unique Identifier)) which identifies device vendor information.
It is possible for a central device/access point to bridge an individual Ethernet port, or bridge the active port according to the DHCP message content received from a LAN host (e.g., DHCP option 43 or option 60 can identify the client's vender information), but these solutions have various limitations and inconveniences. In order to bridge one specific port, the port must be identified and labeled on the box. Moreover, the port may go unused where a user does not need a dedicated bridged port. Dynamic bridging based on DHCP options requires the addition of an extra application process to inspect the DHCP message, which can introduce a risk of being attacked by a fake host to alter the DHCP option. Further an additional switch or hub connected to the central device/access point may cause an issue by unexpectedly bridging multiple hosts. Therefore, a need exists for improving upon methods and systems for bridging data packets received at a central device/access point.
Like reference numbers and designations in the various drawings indicate like elements.